


Tôi từng được tham gia phỏng vấn với mấy anh chị leader team BA lúc trước. Họ thường hỏi ứng viên câu hỏi là: Theo em khi nào thì BA hoàn tất việc thu thập yêu cầu? Câu trả lời thường thấy nhất là: Không bao giờ kết thúc? Và thường câu trả lời này […]

ERD – Entity Relationship Diagram (hay sơ đồ mối quan hệ thực thể) Nghe tên là thấy sặc mùi kỹ thuật rồi. BA xuất thân business giờ nhiều lắm (chẳng hạn như mình), nên cái gì nặng kỹ thuật thì ngán lắm. Nhưng mà cái này nên biết, hoặc có thể nói là phải học […]

Đó là câu hỏi mà bạn không hỏi. Bất ngờ chưa bà già! Đúng rồi, nếu bạn có 1 câu cần hỏi stakeholder và bạn không thốt ra được câu hỏi đó khỏi miệng. Đó chính là bẽn lẽn không cần thiết và có thể dẫn tới một sai lầm. Khi đặt 1 câu hỏi, […]

Bạn đã define requirement một cách ngon lành, dự án đang chạy, team đang deliver đúng tiến độ. Bỗng nhiên, business requirement có sự thay đổi. Trong một thị trường chuyển động nhanh và cạnh tranh khốc liệt như hiện nay, việc kỳ vọng những yêu cầu business luôn cố định một chỗ và stakeholder […]

Outline Dev sẽ nói câu này trong tình huống nào? Tại sao họ nói vậy, gốc rễ vấn đề, có nguyên nhân nào xuất phát từ BA hay không. Có hiểu lầm nào có thể xảy ra không Có thể giải quyết không? Giải quyết như thế nào? Mindset để tiếp cận việc này là […]

Có lẽ ai làm công nghệ theo mô hình agile cũng sẽ quen với khái niệm product backlog. Nếu lên mạng để search từ khóa product backlog là gì, chắc chắn sẽ có rất nhiều bài viết về nó. Nên ở bài viết này, mình sẽ không nói lại quá nhiều những thứ chuyên ngành, […]

Là 1 BA, việc đặt ra những câu hỏi để có thật nhiều thông tin càng tốt và càng sớm càng tốt là 1 kỹ năng thiết yếu. Nhưng đôi khi trong các cuộc thảo luận, chúng ta cảm thấy mình phải hỏi 1 câu gì đó, nhưng chẳng có 1 câu hỏi nào xuất […]

Trong bài nói về các loại diagram nên dùng trong tài liệu BRD, mình đã dùng 1 ví dụ sơ đồ BPM dưới đây. Hôm nay chúng ta hãy đi sâu vào và phân tích từng bước để ra được sơ đồ nhé. Let’s go! Trong bài mình dùng tool Cawemo để vẽ. Đây là […]

Bài trước chúng ta đã bàn về BPM và SCD. Và bây giờ là diagram cuối cùng trong chuỗi bài. Scope model – SM Nếu SCD và BPM là 2 loại sơ đồ ở “tầng cao”. Cho bạn 1 cái nhìn overview thì Scope model – hay Sơ đồ phạm vi sẽ giúp bạn bước […]

Business Process Model – BPM Phần trước chúng ta đã nói về SCD – một cái nhìn toàn cảnh. Hôm nay sẽ bàn về 1 loại tài liệu khác chứa đựng nhiều thông tin hơn. Đó là BPM – lược đồ quy trình nghiệp vụ Nếu SCD là 1 cái địa đồ thô sơ thì […]

Đôi khi 1 ngàn câu nói không bằng 1 tấm hình. Não người có vẻ ưu ái hơn đối với việc xử lý hình ảnh so với xử lý ngôn ngữ. 20 trang giấy của 1 chuyên đề phức tạp có thể được gói gọn vào 1 vài hình ảnh minh họa. Làm BA, bạn […]

1 BA mới thường sẽ gặp vấn đề với việc lấy yêu cầu khi tham gia những dự án đầu tiên mà không được hướng dẫn bởi 1 leader. 1 ví dụ như sau: Ở công ty em không có 1 quy trình lấy requirement chính thức nào cả. Em toàn phải đi lượm lặt […]

Tại sao BA cần 1 framework? Khi mới vào nghề, chúng ta có xu hướng bắt đầu từ các kỹ thuật BA, học cách viết các tài liệu và làm sao để lấy yêu cầu. Bạn gặp may nếu ở công ty của mình cádfasdfó 1 quy trình chuẩn, 1 người leader luôn nói cho […]

Khi bạn tham gia 1 dự án kể từ lúc nó bắt đầu. Có rất nhiều việc để làm với vai trò BA. Bạn nhận yêu cầu từ PM nhà bạn bảo rằng đây là ưu tiên số 1 bây giờ. Đọc qua 1 hồi file brief mà user gửi và…chẳng hiểu gì hết. Bạn […]

Đối với BA, sau khi lấy được requirement từ stakeholder, việc quan trọng tiếp theo chính là ghi nhận các requirement đó thành 1 tài liệu để giao tiếp với stakeholder và team development. Có nhiều cách thức để làm việc đó và trong bài viết này tôi sẽ nói về User story 1 trong […]

Đối với BA, công việc quan trọng nhất chính là lấy được nhiều requirement nhất của user, càng nhiều, càng thầm kín càng tốt. Và một trong những thuật ngữ đẹp đẽ được dùng cho công việc này đó là Requirement Elicitation. Hay Việt hóa là: khơi gợi, đào bới, moi móc nhu cầu từ […]

Viết Là một BA, khi viết 1 requirement, hãy đảm bảo viết 1 cách rõ ràng sáng sủa nhất. Requirement rõ ràng giúp người đọc dễ hiểu đúng requirement, tránh làm sai và lãng phí nguồn lực. Bạn bất lực khi nhận ra 1 từ ngữ nào đó khiến dev team hiểu lầm, và rồi […]